Finalize local message hashes and accept SHA-256 API references - #45
Merged
Conversation
This was referenced Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Local-only sends and reactions acquire their protocol SHA-256 atomically with
time_sent. Mutations share a transaction and row lock, stage file writes, and return success after commit. The shared finalizer retains the immutable wire representation for federation and independently finalizes add-to batches.Expose
sha256/psha256in message, list, WebSocket and structured thread responses, preservingmessage_sha256as an alias. Message routes accept numeric IDs or SHA-256. Requestpidalso accepts original or batch hashes while responsepidstays numeric. Participation checks apply to the referenced branch; batch-only participants use the batch hash to reply.Depends on markmnl/fmsgd#44 (module pinned to its feature commit) and implements markmnl/fmsg#37. Existing installations stop both services and run the standalone
fmsg-backfillbinary, which embeds the schema upgrade and converts existing data atomically. Start the matching services after migration succeeds. The runtime requires finalized storage; only drafts expose null message hashes. Docker integration: markmnl/fmsg-docker#21.Validation: builds, Go tests, PostgreSQL integration tests, race checks and vet passed. Tests cover concurrent sends/edits, rollback and commit rejection, hash authorization, batch replies and WebSocket payloads. The coordinated Docker suite passed all 15 tests with forced challenges, including later federation of locally delivered compressed messages. CI runs the PostgreSQL tests against the schema from the pinned daemon module.